Skip to content

Implement HPX Future-Sender Bridge (P2300 interoperability) - #7256

Merged
hkaiser merged 26 commits into
TheHPXProject:masterfrom
shivansh023023:feat/future-sender-bridge
Aug 2, 2026
Merged

Implement HPX Future-Sender Bridge (P2300 interoperability)#7256
hkaiser merged 26 commits into
TheHPXProject:masterfrom
shivansh023023:feat/future-sender-bridge

Conversation

@shivansh023023

@shivansh023023 shivansh023023 commented May 7, 2026

Copy link
Copy Markdown
Contributor

Implement hpx::future ↔ P2300 Sender Interoperability Bridge

Proposed Changes

  • Added libs/core/futures/include/hpx/futures/future_sender.hpp: implements
    future_sender<T>, a P2300-compliant sender that wraps hpx::future<T>,
    exposing as_sender(hpx::future<T>&&) as the public API entry point
  • Added libs/core/futures/include/hpx/futures/sender_future.hpp: implements
    as_future(sender) which converts any P2300 sender into an hpx::future<T>
    using an internal sender_future_receiver that bridges the two completion
    channels
  • Added libs/core/futures/tests/unit/future_sender_test.cpp: unit tests
    covering future→sender conversion, sender→future conversion, error
    propagation through the error channel, and move-only semantics verification
  • Registered the new test in libs/core/futures/tests/unit/CMakeLists.txt
    following the existing alphabetical ordering convention

Any background context you want to provide?

HPX currently has two async worlds that cannot communicate natively:

  • Legacy world: hpx::async() returns hpx::future<T> (HPX's own type)
  • Modern world: P2300 senders/receivers via the imported stdexec library

This PR builds the translator layer between them, so that existing HPX
code producing futures can be seamlessly composed into modern P2300 pipelines,
and vice versa:

// Direction 1: Future → Sender
hpx::future<int> f = hpx::async([]{ return 42; });
auto [result] = stdexec::sync_wait(
    as_sender(std::move(f)) | stdexec::then([](int x){ return x * 2; })
).value();
// result == 84

// Direction 2: Sender → Future
hpx::future<int> f2 = as_future(stdexec::just(42));
assert(f2.get() == 42);

This is a foundational step toward the broader goal of re-implementing the
executor API on top of the sender/receiver infrastructure (issue #5219), as
it allows hpx::async, hpx::dataflow, and other future-returning facilities
to be gradually migrated into P2300 pipelines without breaking existing user
code.

Implementation follows all established HPX bridge conventions:

  • sender_concept / receiver_concept tags for stdexec concept compliance
  • tag_invoke customization points (no virtual dispatch)
  • HPX_CXX_CORE_EXPORT annotations for C++20 Module BMI visibility
  • Move-only operation states with deferred receiver moves to prevent UB
  • NVCC/CUDACC guards on destructors
  • Zero circular dependencies between the futures and executors modules

Checklist

  • I have added a new feature and have added tests to go along with it.

@shivansh023023
shivansh023023 requested a review from hkaiser as a code owner May 7, 2026 14:23
@codacy-production

codacy-production Bot commented May 7, 2026

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@StellarBot

Copy link
Copy Markdown
Collaborator

Can one of the admins verify this patch?

@hkaiser

hkaiser commented May 7, 2026

Copy link
Copy Markdown
Contributor

@shivansh023023 What's the difference to the existing as_sender(future), make_future(sender), and keep_future(future) facilities we already have (https://github.com/TheHPXProject/hpx/tree/master/libs/core/execution/include/hpx/execution/algorithms)?

@hkaiser hkaiser added type: enhancement type: compatibility issue category: senders/receivers Implementations of the p0443r14 / p2300 + p1897 proposals labels May 7, 2026
@shivansh023023

Copy link
Copy Markdown
Contributor Author

Thank you for pointing this out, @hkaiser I wasn't aware of the existing
as_sender, make_future, and keep_future facilities in
libs/core/execution/include/hpx/execution/algorithms/.

I've now reviewed those headers. Given that the core functionality already
exists, would it be more valuable to:

  1. Extend the existing facilities — for example, ensuring they are
    properly wired to the executor-based schedulers introduced in Implement P2300 get_scheduler bridge for executors #7238
    and Implement P2300 get_scheduler bridge for parallel_executor #7239, so that as_sender(future) preserves the executor context
    from the originating hpx::async() call?

  2. Add missing test coverage — the existing algorithms may lack tests
    for error propagation or move-only semantics that I've written here,
    which could be salvaged into the existing test suite?

  3. Close this PR — if the existing implementation already covers all
    cases correctly, I'm happy to close this and redirect my effort to a
    higher-priority gap.

I'd appreciate your guidance on which direction is most useful. I'm
actively looking for high-impact areas in the S&R domain to contribute
to ahead of GSoC 2027.

@hkaiser

hkaiser commented May 7, 2026

Copy link
Copy Markdown
Contributor
  1. Extend the existing facilities — for example, ensuring they are
    properly wired to the executor-based schedulers introduced in Implement P2300 get_scheduler bridge for executors #7238
    and Implement P2300 get_scheduler bridge for parallel_executor #7239, so that as_sender(future) preserves the executor context
    from the originating hpx::async() call?

If that improves the integration, sure, please do that.

  1. Add missing test coverage — the existing algorithms may lack tests
    for error propagation or move-only semantics that I've written here,
    which could be salvaged into the existing test suite?

If tests are missing this is also a nice addition.

  1. Close this PR — if the existing implementation already covers all
    cases correctly, I'm happy to close this and redirect my effort to a
    higher-priority gap.

That's what I was asking. What would this PR add on top of what's already in place?

@shivansh023023

Copy link
Copy Markdown
Contributor Author

@hkaiser
Would extending as_sender() with an executor-aware overload that calls get_scheduler(exec) and exposes it via get_completion_scheduler be a worthwhile addition, given the new scheduler bridges in #7238 and #7239? Or is there a different integration point you'd prefer?

@hkaiser

hkaiser commented May 18, 2026

Copy link
Copy Markdown
Contributor

@hkaiser Would extending as_sender() with an executor-aware overload that calls get_scheduler(exec) and exposes it via get_completion_scheduler be a worthwhile addition, given the new scheduler bridges in #7238 and #7239? Or is there a different integration point you'd prefer?

Let's go with what you suggest.

@hkaiser

hkaiser commented Jun 4, 2026

Copy link
Copy Markdown
Contributor

@shivansh023023 Do you still plan to work on this PR?

@shivansh023023

Copy link
Copy Markdown
Contributor Author

@shivansh023023 Do you still plan to work on this PR?

yes , i am planning to work on this after #7260

@hkaiser

hkaiser commented Jun 21, 2026

Copy link
Copy Markdown
Contributor

@shivansh023023 Do you still plan to work on this PR?

yes , i am planning to work on this after #7260

FWIW, #7260 has been merged now.

@shivansh023023
shivansh023023 force-pushed the feat/future-sender-bridge branch from 60ba99e to f72c0da Compare June 21, 2026 23:57
@hkaiser

hkaiser commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

@shivansh023023 FWIW, you seem to have missed adding a file to this PR.

@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@shivansh023023

Copy link
Copy Markdown
Contributor Author

@shivansh023023 FWIW, you seem to have missed adding a file to this PR.

Added the file

@hkaiser

hkaiser commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

@shivansh023023 things don't compile, please have a look.

@hkaiser

hkaiser commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

@shivansh023023 ping?

@shivansh023023

Copy link
Copy Markdown
Contributor Author

@shivansh023023 ping?

Sir , my end semester exams are going on , i'll surely look into the issue after 3-4 days

@shivansh023023
shivansh023023 force-pushed the feat/future-sender-bridge branch from ee1f291 to 0dae039 Compare July 4, 2026 17:20
@coderabbitai

coderabbitai Bot commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 59f24213-a319-412b-aaf2-21565dd69ed2

📥 Commits

Reviewing files that changed from the base of the PR and between 606bc42 and 6051377.

📒 Files selected for processing (1)
  • libs/core/execution/tests/performance/future_sender_bridge.cpp

📝 Walkthrough

Summary by CodeRabbit

  • New Features
    • Added bidirectional conversion between HPX futures and experimental P2300-style senders via as_sender and as_future.
    • Added scheduler-aware bridging for value, void, and error completion.
    • Introduced a bridging sender used for future-based sender pipelines.
  • Bug Fixes
    • Improved integration so as_sender keeps the optimized continues_on behavior and correctly forwards scheduler semantics.
  • Tests
    • Added unit tests covering conversions, error propagation, move/copy semantics, and scheduler handling.
    • Extended performance tests with future_sender_bridge (including updated benchmark cases/labels).

Walkthrough

Adds bidirectional conversion between HPX futures and P2300-style senders, registers and tests the adapters, adds a future-sender benchmark, and updates benchmark comments and header-list ordering.

Changes

Future-Sender Bridge

Layer / File(s) Summary
Future-to-sender adaptation
libs/core/execution/include/hpx/execution/algorithms/future_sender.hpp, libs/core/execution/include/hpx/execution/algorithms/as_sender.hpp
Adds future sender operation states, completion signatures, error handling, scheduler metadata, and as_sender integration.
Sender-to-future adaptation
libs/core/execution/include/hpx/execution/algorithms/sender_future.hpp
Adds as_future<T>, mapping sender completion, errors, and stopped signals into an HPX promise and future.
Bridge validation and build wiring
libs/core/execution/CMakeLists.txt, libs/core/futures/CMakeLists.txt, libs/core/execution/tests/unit/*
Registers headers and tests, configures the Clang test setting, and validates conversion, scheduling, errors, ownership, and fused continues_on behavior.
Bridge benchmark coverage
libs/core/execution/tests/performance/CMakeLists.txt, libs/core/execution/tests/performance/future_sender_bridge.cpp
Adds timing coverage for direct future access and three future-to-sender execution paths.
Benchmark comment relabeling
libs/core/execution/tests/performance/benchmark_continues_on.cpp
Updates microbenchmark, macrobenchmark, and subsection comment wording without changing executable operations.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant HPXFuture
  participant FutureSender
  participant Receiver
  HPXFuture->>FutureSender: connect(receiver)
  FutureSender->>HPXFuture: register continuation
  HPXFuture-->>FutureSender: value or exception
  FutureSender->>Receiver: set_value or set_error
Loading
sequenceDiagram
  participant Sender
  participant AsFuture
  participant Promise
  participant HPXFuture
  AsFuture->>Sender: connect receiver
  AsFuture->>Sender: start operation
  Sender->>Promise: set value, error, or stopped
  Promise-->>HPXFuture: make future ready
Loading

Possibly related PRs

  • TheHPXProject/hpx#7397: Directly overlaps with the as_sender adapter refactor, new future_sender.hpp implementation, and related CMake wiring.

Suggested labels: category: core

Suggested reviewers: hkaiser

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 20.48% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed It clearly summarizes the new HPX future↔sender interoperability bridge and matches the main code changes.
Description check ✅ Passed It describes the same future-sender interoperability feature and associated tests, so it is on-topic.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
libs/core/futures/include/hpx/futures/future_sender.hpp (1)

21-27: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Add a direct include for try_catch_exception_ptr.

hpx::detail::try_catch_exception_ptr is used in start_helper (Lines 82, 89, 153, 156) but this header only includes config/future/execution_base and relies on a transitive include. sender_future.hpp correctly pulls in <hpx/modules/errors.hpp>; add it here too to avoid a fragile dependency.

♻️ Suggested include
 `#include` <hpx/config.hpp>
 `#include` <hpx/futures/future.hpp>
+#include <hpx/modules/errors.hpp>
 `#include` <hpx/modules/execution_base.hpp>
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@libs/core/futures/include/hpx/futures/future_sender.hpp` around lines 21 -
27, The header for future_sender uses hpx::detail::try_catch_exception_ptr in
start_helper but does not include the header that declares it, relying on a
transitive dependency. Update future_sender.hpp to add the direct include for
hpx/modules/errors.hpp alongside the existing HPX includes so start_helper is
self-contained and no longer depends on indirect includes.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@libs/core/futures/include/hpx/futures/future_sender.hpp`:
- Around line 11-17: The usage example in future_sender.hpp refers to
hpx::execution::experimental::as_sender, but this header only exposes
future_sender<T>. Update the doc block to match the actual API used here, or add
the missing as_sender factory if that is intended; keep the example consistent
with future_sender and the stdexec usage shown.

---

Nitpick comments:
In `@libs/core/futures/include/hpx/futures/future_sender.hpp`:
- Around line 21-27: The header for future_sender uses
hpx::detail::try_catch_exception_ptr in start_helper but does not include the
header that declares it, relying on a transitive dependency. Update
future_sender.hpp to add the direct include for hpx/modules/errors.hpp alongside
the existing HPX includes so start_helper is self-contained and no longer
depends on indirect includes.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a41a19aa-fe9b-40b7-b692-72db2cb272cb

📥 Commits

Reviewing files that changed from the base of the PR and between 41bf79c and e4746d1.

📒 Files selected for processing (6)
  • libs/core/execution/tests/performance/benchmark_continues_on.cpp
  • libs/core/futures/CMakeLists.txt
  • libs/core/futures/include/hpx/futures/future_sender.hpp
  • libs/core/futures/include/hpx/futures/sender_future.hpp
  • libs/core/futures/tests/unit/CMakeLists.txt
  • libs/core/futures/tests/unit/future_sender_test.cpp

Comment thread libs/core/futures/include/hpx/futures/future_sender.hpp Outdated
- Bridge hpx::future<T> with P2300 senders.
- Resolve header isolation test failures by using targeted futures includes.

Signed-off-by: Shivansh Singh <singhshivansh023@gmail.com>
Signed-off-by: Shivansh Singh <singhshivansh023@gmail.com>
- Replaced deep internal module headers with <hpx/modules/futures.hpp> in tests to comply with C++20 modules constraints.
- Removed non-ASCII characters (em-dashes, arrows, section symbols) across source files and tests to resolve hpxinspect violations.

Signed-off-by: Shivansh Singh <singhshivansh023@gmail.com>
…re_sender_test

Signed-off-by: Shivansh Singh <singhshivansh023@gmail.com>
Signed-off-by: Shivansh Singh <singhshivansh023@gmail.com>
Signed-off-by: Shivansh Singh <singhshivansh023@gmail.com>
@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
libs/core/execution/tests/unit/future_sender_test.cpp (1)

122-141: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Good addition for shared_future copyability, but consider covering void result types too.

This test exercises shared_future<int>, but the PR history notes CI failures were specifically caused by incompatible completion signatures for future<void> and shared_future<int>. Adding a future<void>/shared_future<void> round-trip test here would directly guard against regressing that exact fix.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@libs/core/execution/tests/unit/future_sender_test.cpp` around lines 122 -
141, Add a void-result round-trip test alongside
test_shared_future_copyable_semantics, covering both future<void> and
shared_future<void> through as_sender and sync_wait. Verify the sender pipeline
completes successfully without requiring a value, directly guarding compatible
completion signatures while preserving the existing int copyability assertions.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@libs/core/execution/tests/unit/future_sender_test.cpp`:
- Around line 122-141: Add a void-result round-trip test alongside
test_shared_future_copyable_semantics, covering both future<void> and
shared_future<void> through as_sender and sync_wait. Verify the sender pipeline
completes successfully without requiring a value, directly guarding compatible
completion signatures while preserving the existing int copyability assertions.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 658b90a9-a43f-4d9f-a1bd-e7273004e190

📥 Commits

Reviewing files that changed from the base of the PR and between 1989260 and ce839d0.

📒 Files selected for processing (3)
  • libs/core/execution/include/hpx/execution/algorithms/as_sender.hpp
  • libs/core/execution/include/hpx/execution/algorithms/future_sender.hpp
  • libs/core/execution/tests/unit/future_sender_test.cpp
🚧 Files skipped from review as they are similar to previous changes (1)
  • libs/core/execution/include/hpx/execution/algorithms/as_sender.hpp

Signed-off-by: guptapratykshh <pratykshgupta9999@gmail.com>
Signed-off-by: guptapratykshh <pratykshgupta9999@gmail.com>
Signed-off-by: guptapratykshh <pratykshgupta9999@gmail.com>
Signed-off-by: guptapratykshh <pratykshgupta9999@gmail.com>

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
libs/core/execution/include/hpx/execution/algorithms/future_sender.hpp (1)

35-49: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Drop get_completion_scheduler<set_stopped_t> from the env
future_sender_with_scheduler::env advertises a stopped completion scheduler, but these senders only complete with set_value_t and set_error_t. That makes downstream sender composition ill-formed. Restrict the query to set_value_t unless the sender can actually complete with set_stopped_t.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@libs/core/execution/include/hpx/execution/algorithms/future_sender.hpp`
around lines 35 - 49, Update future_sender_with_scheduler::env so its
get_completion_scheduler query no longer advertises set_stopped_t; restrict the
environment’s completion-scheduler support to set_value_t, matching
future_sender_completion_signatures, while preserving set_error_t handling.
🧹 Nitpick comments (1)
libs/core/execution/include/hpx/execution/algorithms/as_sender.hpp (1)

26-121: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Remove the obsolete sender wrappers as_sender_t now constructs detail::future_sender / detail::future_sender_with_scheduler, and as_sender_sender_with_scheduler still routes through the legacy as_sender_operation_state. These detail types are only referenced here, so the old wrapper can go with the other obsolete implementation.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@libs/core/execution/include/hpx/execution/algorithms/as_sender.hpp` around
lines 26 - 121, Remove the obsolete as_sender_operation_state class and its
related implementation from this header, since as_sender_t now uses
detail::future_sender and detail::future_sender_with_scheduler while
as_sender_sender_with_scheduler should no longer depend on the legacy state.
Clean up any now-unused declarations or references tied exclusively to this
wrapper.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@libs/core/execution/include/hpx/execution/algorithms/future_sender.hpp`:
- Around line 35-49: Update future_sender_with_scheduler::env so its
get_completion_scheduler query no longer advertises set_stopped_t; restrict the
environment’s completion-scheduler support to set_value_t, matching
future_sender_completion_signatures, while preserving set_error_t handling.

---

Nitpick comments:
In `@libs/core/execution/include/hpx/execution/algorithms/as_sender.hpp`:
- Around line 26-121: Remove the obsolete as_sender_operation_state class and
its related implementation from this header, since as_sender_t now uses
detail::future_sender and detail::future_sender_with_scheduler while
as_sender_sender_with_scheduler should no longer depend on the legacy state.
Clean up any now-unused declarations or references tied exclusively to this
wrapper.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8c8b75bb-2dc3-4d52-a2c6-a2664ffea3d1

📥 Commits

Reviewing files that changed from the base of the PR and between ce839d0 and a1c8d28.

📒 Files selected for processing (5)
  • libs/core/execution/include/hpx/execution/algorithms/as_sender.hpp
  • libs/core/execution/include/hpx/execution/algorithms/future_sender.hpp
  • libs/core/execution/tests/performance/CMakeLists.txt
  • libs/core/execution/tests/performance/future_sender_bridge.cpp
  • libs/core/execution/tests/unit/future_sender_test.cpp

@hkaiser

hkaiser commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

@shivansh023023 please resolve the merge conflict and pay attention to the coderabbit comments. Those seem to be legit.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
libs/core/execution/tests/unit/future_sender_test.cpp (1)

185-200: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Verify copyability by asserting or explicitly copying the sender.

The test's stated goal is to verify that the shared_future path remains copyable. However, the current code moves snd into sync_wait without ever evaluating its copy semantics, which leaves the copyability unverified.

Consider adding a compile-time assertion and explicitly copying the sender to validate its copyability.

♻️ Proposed refactor to test copyability
 void test_as_sender_with_scheduler_shared_future()
 {
     ex::thread_pool_scheduler sched{};
     hpx::shared_future<int> f = hpx::make_ready_future(13);
 
     auto snd = ex::as_sender(f, sched);
+    static_assert(std::is_copy_constructible_v<decltype(snd)>);
+    auto snd_copy = snd;
+
     auto result =
-        tt::sync_wait(std::move(snd) | ex::then([](int x) { return x + 1; }));
+        tt::sync_wait(std::move(snd_copy) | ex::then([](int x) { return x + 1; }));
 
     HPX_TEST(result.has_value());
     HPX_TEST_EQ(std::get<0>(*result), 14);
 }
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@libs/core/execution/tests/unit/future_sender_test.cpp` around lines 185 -
200, Update test_as_sender_with_scheduler_shared_future to verify the sender’s
copyability explicitly: add a compile-time copyability assertion for the sender
type and create a copied sender before invoking sync_wait, while preserving the
existing result validation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@libs/core/execution/tests/unit/future_sender_test.cpp`:
- Around line 185-200: Update test_as_sender_with_scheduler_shared_future to
verify the sender’s copyability explicitly: add a compile-time copyability
assertion for the sender type and create a copied sender before invoking
sync_wait, while preserving the existing result validation.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4b61f3b4-761b-405c-af93-d9828f72c0a2

📥 Commits

Reviewing files that changed from the base of the PR and between ce839d0 and a1c8d28.

📒 Files selected for processing (5)
  • libs/core/execution/include/hpx/execution/algorithms/as_sender.hpp
  • libs/core/execution/include/hpx/execution/algorithms/future_sender.hpp
  • libs/core/execution/tests/performance/CMakeLists.txt
  • libs/core/execution/tests/performance/future_sender_bridge.cpp
  • libs/core/execution/tests/unit/future_sender_test.cpp
🚧 Files skipped from review as they are similar to previous changes (3)
  • libs/core/execution/tests/performance/CMakeLists.txt
  • libs/core/execution/include/hpx/execution/algorithms/as_sender.hpp
  • libs/core/execution/include/hpx/execution/algorithms/future_sender.hpp

@guptapratykshh

Copy link
Copy Markdown
Contributor

@shivansh023023, I checked the merge conflict on #7256. It is only in libs/core/execution/tests/performance/CMakeLists.txt, because master added future_boundary and this PR added future_sender_bridge on the same benchmark list line

Signed-off-by: Shivansh Singh <singhshivansh023@gmail.com>
@shivansh023023

shivansh023023 commented Jul 20, 2026

Copy link
Copy Markdown
Contributor Author

@hkaiser , @guptapratykshh the conflicts have been resolved and the coderabbit suggestion is implemented too

@hkaiser

hkaiser commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

@hkaiser , @guptapratykshh the conflicts have been resolved and the coderabbit suggestion is implemented too

There is still one minor issue: https://cdash.rostam.cct.lsu.edu/viewBuildError.php?buildid=65628

Signed-off-by: guptapratykshh <pratykshgupta9999@gmail.com>
execution: fix future sender benchmark comment
@shivansh023023

Copy link
Copy Markdown
Contributor Author

@hkaiser lmk how things look to you

@hkaiser

hkaiser commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Signed-off-by: guptapratykshh <pratykshgupta9999@gmail.com>
execution: avoid deprecated volatile compound assignment

@hkaiser hkaiser left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@hkaiser hkaiser added this to the 2.0.0 milestone Aug 2, 2026
@hkaiser

hkaiser commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

@shivansh023023 Sorry for the delay. Great work.

@hkaiser
hkaiser merged commit 9953b00 into TheHPXProject:master Aug 2, 2026
91 of 102 checks passed
@coderabbitai coderabbitai Bot mentioned this pull request Aug 2, 2026
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

category: senders/receivers Implementations of the p0443r14 / p2300 + p1897 proposals type: compatibility issue type: enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants